The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
In computer software development, version control systems are used to track and manage computer program source code as the code is written and revised. Version control systems include centralized version control systems and distributed version control systems. Centralized version control systems typically manage a single copy of a project in a centralized location such as a server computer, and programmers commit changes to the central copy.
Distributed version control systems include MERCURIAL, GIT, and BAZAAR, and do not necessarily use a centralized server computer to store all versions of the code. Each programmer may create a copy of the program source code, termed a clone, which is locally stored in a repository of that programmer or a group; the repository maintains metadata representing a complete history of a project involving the original code, the programmer's changes, and often changes of other programmers. Software development environments with distributed version control systems typically enable programmers to create, revise and store computer program source code in the form of text files. The development system typically saves a revision to source code by overwriting an existing version of a source code file with a new version of the file. If a programmer revises the source code, stores the new version in the file, compiles the new version of the file, and learns that the execution of the compiled new version results in an error, the programmer may be able to identify the specific revision that introduced the error if the programmer can restore the old version of the file. A development system with a version control feature can facilitate the identification of errors by enabling a programmer to access previous and current versions of the source code. These environments support operation with many users who are widely distributed across distant geographic locations yet working on the same source code project, by communication over internetworks.
This approach enables each user to have a full history of the source code. The second copy of the repository may be termed a fork, and the original repository on the server computer may be termed a canonical, main repository, or upstream repository. The system also may enable a user to duplicate or clone the fork, store the clone on the user's computer, work on the clone, and then merge the clone back to the upstream repository, or merge the clone back to a clone of the fork that is on the server computer. With this approach, many users can work on clones of the fork and exchange revisions. Unfortunately, some systems can manage and control such clones and forks only using relatively simple features of a file system of the operating system on which the systems operate. For example, the GIT distributed version control system may use UNIX operating system filesystem permissions to control read and write access to GIT repositories of source code. This approach is unsophisticated and cannot manage conflicts arising from attempts of multiple different users to merge their different clones into the same repository on the server computer.